home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 373 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.9 KB
  1. Path: cs.tu-berlin.de!jutta
  2. From: jutta@cs.tu-berlin.de (Jutta Degener)
  3. Newsgroups: comp.std.c
  4. Subject: Re: setjmp usage question
  5. Date: 25 Feb 1996 12:24:24 GMT
  6. Organization: Technical University of Berlin, Germany
  7. Message-ID: <4gpkdo$jm8@news.cs.tu-berlin.de>
  8. References: <4gnusq$7be@senator-bedfellow.MIT.EDU>
  9. NNTP-Posting-Host: kugelbus.cs.tu-berlin.de
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=iso-8859-1
  12. Content-Transfer-Encoding: 8bit
  13.  
  14. tada@athena.mit.edu (Michael J Zehr) writes:
  15. > I'm trying to determine whether a particular usage of setjmp is
  16. > sanctioned by the standard and I'm finding a compiler bug or whether my
  17. > usage is non-conforming.
  18.  
  19. Your usage is non-conforming.  The reason for that is not important
  20. to what you're asking, but I'll mention it to get it out of the way.
  21. The standard has restricted the ways in which setjmp() can be used:
  22.  
  23. #         An invocation of the "setjmp" macro shall appear only in one of
  24. # the following contexts:
  25. # 
  26. #       * The entire controlling expression of a selection of iteration
  27. #         statement;
  28. # 
  29. #       * one operand of a relational or equality operator with the
  30. #         other operand an integral constant expression, with the resulting
  31. #         expression being the entire controlling expression of a selection
  32. #         or iteration statement;
  33. # 
  34. #       * the operand of a unary ! operator with the resulting expression
  35. #         being the entire controlling expression of a selection or iteration
  36. #         statement; or
  37. # 
  38. #       * the entire expression of an expression statement (possibly cast
  39. #         to void).
  40. #                        --- ANSI Section 4.6.1.1
  41.  
  42. Your statement, 
  43.  
  44. >    if (*error_code = setjmp(env[env_index++])) {
  45.  
  46. is neither of these cases (the '=' means assignment, not equality), so the
  47. program's behavior is undefined.
  48.  
  49. Let's imagine you had written
  50.  
  51.     if (setjmp(env[env_index++])) {
  52.  
  53. > Should this code work correctly?  In particular, can a compiler
  54. > increment env_index after longjmp is called?
  55.  
  56. I think the code might or might not work, and the compiler is free to
  57. increment env_index after longjmp is called and flow control has returned
  58. to the setjmp statement.  The standard doesn't impose any ordering on
  59. the act of "returning" from the longjmp invocation and on the side
  60. effects from the setjmp() statement---macro invocations like setjmp()
  61. do not imply sequence points in the way function invocations do.
  62.  
  63. > [Additional question because I'm curious:  what happens to
  64. > post-increments that are in parameters of the longjmp call?
  65.  
  66. I think that unless you take special care, the same applies, but you'll
  67. find people to argue otherwise.  (See below.)
  68.  
  69. For a bit of background---
  70.  
  71. The standard specifies one type of sequence point that's interesting
  72. for us here: 
  73.  
  74. #       The order of evaluation of the function designator, the arguments,
  75. #  and subexpressions within the arguments is unspecified, but there is a
  76. #  sequence point before the actual call.
  77. #
  78. #                --ANSI section 3.3.2.2, Function Calls.
  79.  
  80. That this is the only place that applies is in itself significant: there
  81. are no special sequence points for longjmp and setjmp; they behave just
  82. like any old function---or macro.
  83.  
  84. Setjmp, although it looks much like a function, is not described as a
  85. function in the standard; it is a macro.  Among other things, that means
  86. you can't rely on a sequence point between the evaluation of setjmp's
  87. argument and the "call".
  88.  
  89. Longjmp is described as a function in the standard.  Does that mean it
  90. is a function?  Yes and no.  There is a function called longjmp, and if
  91. you write a call
  92.  
  93.     #include <setjmp.h>
  94.     (longjmp)(env[env_index++], 1);
  95. or
  96.     #include <setjmp.h>
  97.     #undef longjmp
  98.     longjmp(env[env_index++], 1);
  99. or
  100.     #include <setjmp.h>
  101.     void (* f)(jmp_buf, int) = longjmp;
  102.     f(env[env_index++], 1);
  103.  
  104. so that longjmp can't possibly be a macro, you are guaranteed to get
  105. a real function, complete with sequence point and all.  In these cases,
  106.  
  107.     (longjmp)(env[env_index++], 1);
  108.  
  109. is equivalent to
  110.  
  111.     env_index++; longjmp(env[env_index - 1], 1);
  112.  
  113. since the side effects of the "++" operator must be complete before
  114. the actual function is invoked.
  115.  
  116. But as long as you don't jump through any of the three hoops above
  117. and naively use
  118.  
  119.     #include <setjmp.h>
  120.     longjmp(env[env_index++], 1);
  121.  
  122. what you actually get may or may not be a call to the "real" longjmp
  123. function, because 
  124.  
  125. #     Any function declared in a header may be additionally
  126. #   implemented as a macro
  127. #
  128. #        -- ANSI Section 4.1.6, Use of Library Functions
  129.  
  130. Whether this means that
  131.  
  132. (a) users cannot rely on the sequence point between argument evaluation
  133.     and call unless they make sure they're using a "real" function
  134.  
  135. or whether this means that
  136.  
  137. (b) implementors who implement Standard C functions as macros must
  138.     guarantee that function-call like sequence points apply even in 
  139.     the macro expansions
  140.  
  141. hasn't been formally decided within WG14 yet, as far as I remember.
  142.  
  143. Jutta Degener (jutta@cs.tu-berlin.de), speaking only for myself.
  144.